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iQlrQfluclion 


This  paper  describes  a research  project  of  the  Computer 
Systems  Research  Oivlslon  of  Project  MAC  at  M.I.T.  The  objective 
of  the  project  is  to  engineer  a security  kernel  for  Multlcs. 
This  project  is  part  of  an  effort  to  develop  a secure  version  of 
Multlcs  that  Implements  the  Information  release  constraints  of 
the  military  security  system.  Involved  In  that  effort  are  the 
Electronic  Systems  Oivlslon  of  the  United  States  Air  Force,  the 
MITRE  Corporation*  and  Honeywell  Information  Systems  Inc. 

The  paper  starts  with  a brief  Introduction  to  the  coaputer 
security  problem  and  the  role  that  verification  of  correctness 
plays  in  producing  a secure  system.  Next*  the  plan  Is  outlined 
for  evolving  Multlcs  Into  a system*  based  on  a security  kernel* 
whose  security  properties  are  easier  to  verify.  The  third 
section  presents  a general  discussion  of  a security  kernel  as  the 
structural  basis  for  a secure  system.  Finally*  to  make  the 
nature  of  the  Multlcs  kernel  project  more  precise*  a sample  of 
specific  activities  underway  or  planned  Is  presented. 

The  Issue  of  security  arises  when  a single  computer  system 
provides  computation  and  Information  storage  service  to  a 
community  of  users.  As  the  functional  advantages  of  such  shared 
systems  have  been  recognized*  so  has  the  need  to  Include 
facilities  for  controlling  the  access  of  the  various  users  to  the 
contained  Information.  Many  systems  now  include  protection 
mechanisms  providing  enforcement  of  specific  patterns  of 
externally  specified  constraints  on  the  access  of  executing 
programs  to  the  contained  information  (ll.  For  applications 
Involving  sensitive  Information*  the  usefulness  of  a shared 
system  can  depend  upon  the  ability  of  Its  protection  mechanisms 
to  prevent  unauthorized  release*  modification*  and  sometimes 
denial  of  use  of  the  Information  It  contains. 

A system  Is  secure  if  It  Is  known  to  prevent  all  actions 
defined  as  unauthorized  by  the  specification  of  Its  security 
properties.  Penetration  exercises  Involving  several  different 
systems  have  made  It  apparent  that  existing  shared* 
general-purpose  systems  are  not  secure.  In  all  such  systems 
confronted*  a wily  user  can  construct  a program  that  can  defeat 
the  access  constraints  supposedly  enforced  by  the  system.  Oesign 
and  Implementation  flaws  exist  that  provide  paths  by  which  the 
protection  mechanisms  in  the  system  can  be  circumvented*  thus 
violating  the  security  of  the  contained  information. 

Building  a secure  system  Is  hard  because  security  places 
negative  requirements  on  a system.  To  be  secure  all  possible 
ways  to  perform  unauthorized  actions  must  be  blocked*  Q£  way  to 
circumvent  the  protection  mechanisms  can  exist.  A single  flaw  in 
the  design  or  Implementation  is  sufficient  to  allow  a violation 
of  security*  and  the  absence  of  such  flaws  cannot  be  demonstrated 
by  testing.  EfiC.  d SKS.tll  Id  &£  COOSl SAdiICA*  £ ggP^lDClD-fl 
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laalcal  verification  imi  ilia  ijiaiflnflQl&d  sits  is  i is  a gaccacl 
cjtalizflllflp  a!  iis  safiiiciijf  soficillsiliflQ  is  cimULcad* 


The  operating  systems  of  shared*  general-purpose  computers 
have  a well-known  tendency  to  be  extraordinarily  large  and 
complex.  This  size  and  complexity  Interacts  badly  with  the 
negative  nature  of  security  requirements.  It  generates  many 
possible  ways  to  perform  unauthorized  actions*  some  of  which  will 
go  unnoticed  by  system  designers  and  therefore  remain  unblocked 
by  the  protection  mechanisms  provided,  and  Increases  the 
probability  of  exploitable  errors  In  the  Implementation  of  the 
protection  mechanisms  that  are  provided.  It  also  makes  the 
required  verification  of  correctness  Impossible  to  perform. 
Available  formal  program  verification  techniques  are  overwhelmed 
and  even  verification  by  manual  auditing  Is  thwarted  by  the 
Inability  of  one  person  to  comprehend  In  detail  the  relevant 
so  f tware. 

The  negative  nature  of  security  properties  is  an  Intrinsic 
problem.  The  size  and  complexity  of  existing,  shared, 
genera l-purpose  systems,  however.  Is  not  Intrinsic.  This 
research  project  attacks  the  problem  of  producing  a secure  system 
by  exploring  ways  to  reduce  the  size  and  complexity  of  the 
software  that  must  be  correct  for  claimed  constraints  on  access 
to  Information  to  be  enforced. 

Iteitifld  fil  Alias* 

The  problem  of  constructing  a secure  system  has  attracted 
considerable  Interest  recently  and  is  being  attacked  with  a 
variety  of  different  strategies  (21.  One  approach  being  explored 
involves  constructing  a formal  specification  for  the  desired 
security  (and  other)  properties  of  a system,  and  then,  through  a 
methodical,  top-down  design  and  Implementation  process,  building 
a matching,  operational  system.  The  correspondence  of  the 
Implemented  system  with  the  formal  security  specification  Is  to 
be  proved  using  formal  program  verification  techniques.  The  hope 
is  to  achieve  a level  of  confidence  In  the  match  of  the  system  to 
the  specification  slmlliar  to  the  confidence  that  a mathematician 
has  in  the  result  of  a well-wrought  proof.  A step  necessarily 
left  to  human  intuition  Is  determining  how  appropriate  the 
security  properties  expressed  In  the  formal  specification  are  to 
a particular  real-world  application.  Three  current  projects 
(3,4,51  are  trying  to  proouce  simple,  experimental  examples  of 
secure  systems  using  different  versions  of  this  approach. 

At  the  other  end  of  the  spectrum  are  efforts  (6, 7]  to  find, 
catalog,  and  repair  security  flaws  in  existing  systems.  The 
goals  are  to  convince  skeptics  that  the  computer  security  problem 
is  real,  to  understand  the  sort  of  flaws  that  can  be  exploited, 
and  to  try  to  reduce  the  ease  with  which  available  systems  can  be 
penetrated. 
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Our  project  to  reduce  the  size  and  complexity  of  the 
software  that  must  be  verified  correct  to  produce  a secure  system 
falls  somewhere  between  these  two  extremes.  Our  plan  Is  to 
evolve  Hu  I tics  (81*  a general-purpose*  remotely  accessed* 
multiuser  system*  Into  a prototype  system  with  the  same  essential 
features*  but  with  a small  and  simple  protected  central  core  of 
software.  This  core  Mill  be  a security  kernel  embodying  all 
mechanisms  necessary  to  enforce  the  claimed  constraints  on  access 
to  Information  In  the  system.  The  goal  Is  a kernel  sufficiently 
small*  we  1 1 -structured*  and  easy  to  understand  that  feasibly  an 
expert  could  verify  Its  correctness  through  manual  auditing. 
Such  a kernel  also  may  be  susceptible  to  verification  through 
formal  techniques*  although  the  programs  may  have  to  be  rewritten 
In  a more  appropriate  style.  The  kernel  will  enforce  access 
constraints  that  combine  ncndlscret lonary  controls  reflecting  the 
Information  release  policies  of  the  military  security  system  and 
the  dlscret lonary  controls  on  Information  sharing  that  were  part 
of  the  original  Hul tics  design.  (1) 

The  choice  to  evolve  an  existing  system  rather  than  produce 
a new  one  follows  from  our  focusing  on  problems  of  system 
structure*  rather  than  on  techniques  for  formal  specification  of 
security  properties*  structured  programming*  or  formal 
verification  of  program  correctness.  Our  goal  Is  developing  a 
security  kernel  that  can  be  demonstrated  to  support  the  full  set 
of  functions  that  are  desirable  In  a shared*  genera  I -purpose 
system.  With  the  current  understanding  of  computer  systems*  It 
Is  hard  to  have  confidence  that  the  full  Implications  of  a system 
structure  are  understood  without  complete  Implementation. 
Designing  a new  system  without  building  It  or  building  a simple* 
experimental  system  (2)  would  not  allow  the  completeness  of  our 
kernel  design  to  be  tested  adequately.  Thus*  to  start  fresh 
would  mean  undertaking  the  entire  Job  of  building  a new* 
general-purpose  system.  By  developing  a security  kernel  for  an 
existing*  general-purpose  system*  we  avoid  this  enormous  effort. 

A combination  of  factors  makes  Hul tics  well  suited  as  a base 
from  which  to  engineer  a security  kernel.  To  start  with*  Hul tics 
provides  a full  set  of  functional  capabilities*  Including 
hlgh-bandwldth  direct  sharing  of  Information  among  computations 
(111.  In  addition*  Hul tics  has  been  developed  from  the  ground  up 
to  protect  the  Information  It  contains  from  unauthorized  access. 
It  already  Includes  general  protection  mechanisms  to  control 


(1)  A formal  specification  [91  of  the  nondlscretlorary  controls 
Is  being  developed  by  a group  at  HITRE.  An  Informal 
specification  of  the  discretionary  controls  Is  available  In  C 1 0 1 • 

(2)  Two  examples  of  features  usually  left  out  of  experimental 
systems  that  can  complicate  the  kernel  of  an  complete* 
general-purpose  system  are  the  storage  quota  and  backup 
mechanisms  mentioned  In  a later  section. 


3 


information  sharing  among  users  (10 1 and  provides  direct  hardware 
support  for  some  of  these  mechanisms  (121.  Minimal  features  to 
support  the  information  release  constraints  of  the  military 
security  system  recently  have  been  added  (13)  • Thus*  the  system 
exhibits  a set  of  security  properties  that  would  be  interesting 
to  implement  correctly  and  provides  hardware  support  that  will 
make  the  Job  easier.  Also*  the  system  is  well  organized  for 
evolution  and  modification  because  it  is  relatively  modular*  is 
largely  written  in  PL/I  (14J*  and  was  originally  constructed  with 
evolution  as  a primary  objective.  Finally*  Multlcs  provides  two 
unique  opportunities  to  test  and  export  the  results.  First* 
because  Multlcs  is  a commercially  available  product*  ideas 
developed  in  the  course  of  this  research  that  simplify  the 
system's  structure  without  changing  its  functionality  or  reducing 
its  efficiency  can  be  added  to  the  standard  system.  Second*  the 
security  kernel  being  produced  is  serving  as  the  structural  basis 
for  the  secure  version  of  Multlcs  being  developed  by  the  Air 
Force*  MITRE*  and  Honeywell  in  an  effort  of  which  our  project  is 
part. 

ID*  SfiCMCil*  KftCQfll 

A security  kernel*  a minimal*  protected  core  of  software 
whose  correct  operation  is  sufficient  to  guarantee  enforcement  of 
the  claimed  constraints  on  access*  is  the  structural  basis  for 
organizing  a secure  system.  Rather  than  being  dispersed 
throughout  the  system  software*  all  protection  mechanisms  are 
collected  in  the  kernel*  so  that  only  this  kernel  need  be 
considered  in  order  to  verify  that  the  specified  security 
properties  are  implementec  correctly. 

The  security  specification  that  a particular  system  must 
match  limits  how  small  and  simple  (3)  the  kernel  can  be.  The 
patterns  of  access  constraints  to  be  enforced  is  an  obvious 
factor.  The  set  of  abstract  objects  and  operations  to  be 
controlled  may  be  even  more  important.  In  Multlcs*  it  appears 
that  most  of  the  mechanism  in  the  kernel  will  implement  the 
abstract  objects  protected  by  the  system*  for  example*  processes* 
segments*  directories*  and  I/O  streams*  and  will  be  relatively 
Independent  of  the  specific  patterns  of  access  constraints 
enforced  by  the  system. 

A characterization  of  the  mechanisms  that  should  be  included 
in  a security  kernel  can  be  obtained  by  viewing  the  security 
specification  as  a set  of  constraints  on  the  interaction  of  the 
various  computations  that  occur  in  a computer  system.  The 
protection  mechanisms  of  the  system  prevent  one  computation  from 
exerting  an  unauthorized  Influence  on  the  input*  progress*  or 
output  of  another.  Permanently  stored  data  is  one  form  of  the 


(3)  Unfortunately*  no  objective  measure  of  overall  complexity  is 
known.  The  degree  of  complexity  must  be  estimated  subjectively. 
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Input  and  output  of  computations.  This  view  suggests  that  the 
security  kernel  should  embody  all  system-provided  mechanisms  that 
are  common  to  more  than  one  computation  (domain),  because  a 
common  mechanism  Is  required  If  one  computation  is  to  Influence 
another.  A mechanism  Is  common  to  two  computations  if  it  uses 
some  set  of  data  Items  whose  value  one  computation  can  Influence 
and  the  other  can  notice.  The  Influence  and  notice  may  be 
direct— one  writes  Into  a data  Item  and  the  other  reads  It — or 
indirect— the  Invocation  of  a procedure  by  one  somehow  alters  the 
procedure's  Internal  state  so  that  the  outcome  of  an  invocation 
by  the  other  Is  affected.  Common  mechanisms  are  required  to 
Implement  any  explicit  or  Implicit  communication  among 
computations.  Thus,  mechanisms  Implementing  Information  sharing. 
Interprocess  communication,  and  physical  resource  multiplexing 
must  be  common.  If  no  communication  Is  Involved,  however,  then  a 
common  mechanism  Is  not  required  to  Implement  a function.  Common 
mechanisms  carry  a built-in  risk— they  make  It  possible  for  the 
computation  of  one  user  to  exert  unauthorized  Influence  over  the 
computations  or  data  of  another.  Malicious  users  must  exploit 
flaws  In  common  mechanisms  to  work  their  will.  To  thwart  such 
malicious  activity  the  system  designers  must  ensure  that  the 
common  mechanisms  have  no  exploitable  design  or  Implementation 
flaws,  and  must  protect  the  common  mechanisms  against  tampering. 
Thus,  a sficudiy  hicpii  itiai/ld  kfi  i&a  mil  ULfiunl  slI  cabeab 
aisbapiia  oaiamc*  la  ijalmol  Ihi  ultAtns  ai  lnlannilao 
stifle  Ida  t lnlacncflciis  caMUDlcallao*  and  nbxilfial  has  a u tree 
aulilpJaxlna  Itial  acj  daiicid  Id  Ilia  szstai*  <4) 

Although  a security  kernel  contains  all  the  mechanisms  that 
must  be  verified  as  correct  to  produce  a secure  system,  a correct 
kernel  does  not  guarantee  the  integrity  of  all  computations  or 
stored  data  In  a system.  Nonkernel  software  still  can  cause 
undeslred  release  of  information,  modification  of  information,  or 
denial  of  Its  use.  But  if  the  kernel  Is  correct,  then  these 
undeslred  results  will  not  be  unauthorized.  To  understand  the 
meaning  of  this  distinction,  consider  the  nonkernel  software  as 
grouped  in  four  categories. 

First,  there  are  the  system-provided  programs  that  execute 
as  part  of  user  computations.  These  Include  the  I Ibrary 
subroutines  available  In  most  systems  and  all  the  programs 
usually  part  of  a supervisor  that  are  not  included  in  a security 
kernel.  These  system- provided  programs  are  not  common 
mechanisms,  even  though  In  many  systems  all  computations  may 


(4)  According  to  this  characterization  of  a security  kernel,  a 
usual  reason  for  Including  a mechanism  In  a supervisor,  to 
protect  It  from  accidentia  I breakage  caused  by  errors  In  user 
code.  Is  not  In  Itself  sufficient  to  Include  a mechanise  In  a 
security  kernel.  Nonkernel  mechanisms  can  be  protected  by 
placing  them  In  other  domains  that  are  private  to  each  user's 
computation. 
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share  the  same  nonmrlteable  code  that  embodies  their  algorithms* 
This  Is  so  because  a private  copy  of  the  alterable  part  of  these 
programs*  the  variable  data*  Is  provided  for  each  computation* 
Because  they  are  private  mechanisms*  no  Interuser  Interaction  can 
occur  through  them*  Private  mechanises  may  contain  errors*  but 
these  errors  can  by  triggered  only  by  the  actions  of  the 
computation  that  they  might  damage  as  a result*  If  one  assumes 
that  the  system  programmers  mho  constructed  them  are  not 
malicious  and  did  not  ml  1 1 fully  plant  **tro|  an  horses***  then  the 
mistakes  caused  by  these  system-provided  programs  mill  oecrease 
In  time  as  all  normally  used  functions  are  exercised*  Under  these 
circumstances  the  threat  posed  by  a potential  random  error 
causing  undeslred  release*  modification*  or  denial  of  a user's 
data  Is  acceptable  for  most  applications*  Unlike  the  common 
mechanisms  of  the  security  kernel*  the  nonkernel  system-provided 
programs  are  not  susceptible  to  mlllful  exploitation  by  other 
users*  In  any  case*  a user  unsatisfied  mlth  their 
trustmorthiness  may  choose  not  to  use  them  and  substitute  his  omn 
programs* 

The  second  category  of  nonkernel  softmare  is  programs 
constructed  by  a user  and  executed  In  that  user*s  computations* 
Any  undeslred  result  caused  by  errors  In  these  Is  the  user's  omn 
problem.  The  only  possible  help  to  the  user  mould  be  providing 
tools  to  aid  verifying  the  correctness  of  his  omn  programs* 

The  third  category*  possible  in  many  systems*  Is  programs 
borromed  from  other  users*  These  are  a real  danger  to  the 
borrower's  computations*  Borromed  programs  can  contain  trolan 
horse  code  maliciously  constructed  to  cause  results  undeslred  by 
the  borrower.  (5)  A user  should  borrom  programs  from  another 
only  mhen  the  borromer  has  reason  to  trust  the  lender.  The 
Inclusion  of  security  kernel  facilities  to  support 
user-constructed  protected  subsystems  can  reduce  the  potential 
damage  such  a borromed  trojan  horse  can  do  by  isolating  it  In  a 
separate  domain  of  the  borromer*s  computation*  Due  to  the 
confinement  problem  H5J*  homever*  and  also  to  the  possibility  of 
a borromed  program  disrupting  the  borromer's  computation  simply 
by  calculating  Incorrect  results*  a user-initiated  verification 
of  the  borromed  program  is  the  only  complete  protection* 

The  fourth  category  Is  common  mechanisms  that  a group  of 
users  sets  up  to  implement  some  function  involving  interuser 
communication  or  coordination.  For  example*  a team  producing  a 
nem  compiler  might  set  up  a program  development  subsystem  mlth  a 
common  mechanism  to  control  installation  of  nem  modules  into  the 


(5)  This  Is  a special  case  of  a common  mechanism*  The  data  Item 
mhose  value  the  lender  can  cause  to  change  (and  thereby  influence 
the  computation  of  the  borromer)  Is  the  code  of  the  borromed 
program  Itself.  Even  If  the  program  Is  nonmrltable  mhen 
borromed*  it  mas  mritten  by  the  lender  mhen  constructed. 
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evolving  compiler*  Such  a mechanise  makes  the  group  susceptible 
to  undeslred  Interaction  In  the  same  may  that  an  Insecure 
supervisor  does  for  the  Mho  le  user  community*  If  a user  agrees 
to  become  party  to  such  a common  mechanism*  then  he  must  satisfy 
himself  of  its  trustworthiness* 

From  considering  these  four  categories  of  nonkernel  software 
it  Is  apparent  that  the  essential  mechanisms  to  verify  correct 
are  the  common  mechanism  of  the  security  kernel*  The  security 
kernel  has  initial  control  of  all  paths  for  the  interaction  of 
computations  and  every  user  of  the  system  is  forced  to  rely  upon 
it*  A correct  kernel  provides  the  tools  Mith  which  a user  may 
protect  his  computations  and  data  against  unwanted  interference 
from  the  computations  of  other  users*  In  a system  providing  for 
direct  sharing  of  programs  and  data*  however*  users  can  agree  to 
cooperate  in  ways  that  the  security  kernel  cannot  control.  The 
kernel  can  prevent  such  sharing  unless  it  is  explicitly 
authorized*  but  cannot  completely  control  the  interaction  between 
user’s  that  agree  to  share.  The  security  kernel  prevents 
activities  that  the  security  specification  for  the  system  defines 
as  unauthorized*  but  not  all  undeslred  results  are  causec  by 
unauthorized  activities* 


A fifth  category  of  nonkernel  software  also  needs  to  be 
considered*  One  important  technique  for  simplifying  the 
structure  of  the  security  kernel  is  writing  it  with  a high-level 
programming  language*  Using  a high-level  language  to  generate 
the  kernel  seems  to  require  that  the  compiler  also  be  verified 
correct*  a troubling  thought  since  the  compiler  may  well  be 
larger  than  the  kernel*  Verification  of  correct  function  may  be 
less  of  a problem  for  the  compiler*  however*  than  for  the  kernel. 
The  kernel  must  work  correctly  for  all  possible  inputs?  the 
compiler  must  compile  correctly  only  the  specific  programs  of  the 
kernel— not  all  possible  programs*  Thus*  the  compiler’s  effect 
on  the  kernel  can  be  determined  by  comparing  the  source  code 
specifications  for  each  kernel  module  with  the  compiler-produced 
object  code  implementation*  a task  ouch  simpler  than  verifying 
the  compiler  correct  for  all  possible  source  programs*  (6) 


A AfiCDfl  ±C£  Bullies 


Engineering  a security  kernel  for  a system  requires 
isolating  a minimum  set  of  functions  capable  of  supporting  the 
system  and  finding  a way  to  structure  the  kernel  to  facilitate 
verifying  its  correctness.  Our  plan  is  to  produce  a security 
kernel  for  Multlcs  by  removing  nonkernel  mechanisms  from  the 
supervisor*  and  restructuring  the  remaining  kernel  and 


(6)  Use  of  a high-level  language  for  kernel  construction  can 
generate  a dilemma*  An  optimizing  compiler  can  increase  system 
efficiency*  but  may  make  impossible  matching  object  code  with 
source  code  to  verify  correct  compiler  function* 
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partitioning  It  Into  multiple  protection  domains*  This  section 
describes  these  three  Interrelated  categories  of  activities  and 
provides  specific  examples  of  work  underway  or  planned  in  each. 
The  intention  of  the  section  Is  to  communicate  the  spirit  of  the 
work  rather  than  to  to  discuss  thoroughly  the  various  activities. 
The  detailed  results  of  Individual  activities  are  being 
communicated  In  other  reports  (16*17*181. 

The  first  category  of  activities  Is  taking  functions  not 
requiring  Implementation  as  common  mechanisms  out  of  the 
supervisor  to  be  Implemented  In  the  user  domains  of  a process* 
In  many  cases  this  transfer  Involves  undoing  a pattern  causec  by 
a performance  characteristic  of  the  original  Multlcs 
Implementation  for  the  Honeywell  645  computer.  For  that  machine* 
the  multiple  protection  domains  of  a process*  the  so-called 
protection  rings*  were  simulated  In  software.  Cross-ring  calls 
were  quite  expensive*  a call  that  went  from  a user  ring  In  a 
process  to  the  supervisor  ring  cost  much  more  than  a call  that 
did  not  change  protection  rings.  The  effect  on  system  structure 
can  be  seen  by  considering  two  procedures*  A and  B.  If  a single 
Invocation  of  A can  result  In  a flurry  of  calls  from  A to  B«  then 
there  Is  a performance  benefit  In  placing  both  A and  8 In  the 
supervisor*  even  If  only  8 needs  to  be  part  of  the  protected* 
common  mechanism.  As  a result  of  this  performance  characteristic 
of  the  645  Implementation*  many  functions  that  did  not  need  to  be 
Implemented  as  common  mechanism  were  Included  In  the  supervisor. 

The  present  hardware  base  for  Multlcs*  the  Honeywell  Series 
60/  Level  68  computer*  Implements  protection  rings  In  hardware. 
Calls  from  one  ring  to  another  cost  no  more  than  calls  inside  a 
ring.  With  the  performance  penalty  associated  with  supervisor 
calls  removed*  many  modules  Included  In  the  supervisor  for 
performance  reasons  rather  than  protection  reasons  now  can  be 
removed.  (7) 

Actually*  removing  a module  from  the  supervisor  is  more 
difficult  than  the  example  suggests.  In  most  cases*  the  common 
and  private  parts  of  a facility  are  not  neatly  packaged  In 
separate  procedures  but  are  Intricately  Intertwined  In  the  same 
supervisor  procedures  and  data  bases.  The  key  problem  Is 
decomposing  the  supervisor  Into  common  and  private  primitive 
functions* 

Host  removal  activities  have  centered  on  the  file  system. 
In  one  activity*  now  completed*  the  functions  of  dynamic 
Intersegment  linking  and  direction  of  file  system  searches  to 


(7)  There  may  still  exist  other  performance  penalties  associated 
with  removing  functions  from  the  supervisor  that  will  inhibit 
production  of  the  smallest  possible  kernel*  One  goal  of  the 
research  Is  to  understand  better  the  performance  cost  of 

security. 
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satisfy  symbolic  references  have  been  removed  f roe  the  supervisor 
(16*17).  This  removed  a vulnerable  and  complex  Mechanise  froa 
the  supervisor.  The  vulnerability  Is  a result  of  the  linker 
having  to  accept  user-constructed  code  segaents  as  Input  data. 
Nuaerous  accidents  had  shown  that  such  a complex  "argument***  If 
maliciously  alsstructured*  could  cause  the  linker  to  malfunction 
while  executing  In  the  supervisor.  Removing  the  linker 
eliminated  10X  of  the  gate  entry  points  Into  the  supervisor  and 
6X  of  the  total  object  code.  The  linker’s  removal  also 
demonstrated  that  linking  procedures  together  across  protection 
boundaries  (rings)  could  be  done  without  resorting  to  a mechanism 
common  to  both  domains. 

A second  completed  activity  removed  from  the  supervisor  the 
facilities  for  managing  the  association  between  reference  names 
and  the  segaents  In  the  address  space  of  a process  (16).  Taking 
this  naming  mechanism  out  of  the  supervisor  required  that  a data 
base  central  to  the  management  of  the  address  space*  the  Known 
Segment  Table*  be  split  Into  a private  part  that  maintains  the 
binding  between  reference  names  and  segment  numbers  and  a common 
part  that  maintains  the  binding  between  segment  numbers  and 
segments.  Removal  reduced  fivefold  the  size  of  the  protected 
code  needed  to  manage  the  address  space  of  a process.  It  also 
provided  a new*  simpler  Interface  to  the  file  system  portion  of 
the  supervisor.  Instead  of  Identifying  a directory  by  character 
string  tree  name  locating  It  In  the  file  system  hierarchy*  a 
segment  number  now  Is  used.  The  algorithms  for  following  a tree 
name  through  the  film  system  hierarchy  to  locate  the  named 
element  are  now  Implemented  by  procedures  executing  In  the  user 
ring.  (The  actual  file  system  hierarchy  remains  protected  Inside 
the  security  kernel.)  Because  tree  names  are  now  resolved  one 
component  at  a time*  the  kernel  had  to  learn  to  lie  on  occasion 
about  the  existence  of  file  system  alrectorles.  This  deception 
keeps  the  kernel  from  divulging  a directory's  existence  before  an 
accessible  element  In  the  subtree  rooted  by  the  directory  is 
found. 


An  activity  under  Investigation  Involves  making  most  of 
system  Initialization  execute  once*  In  a user  environment  of  a 
previous  system  version*  Instead  of  executing  Inside  the 
supervisor  each  time  the  system  Is  started.  The  change  Is  to 
produce  a system  tape  with  a bl t pattern  that*  when  loaded  Into 
memory*  manifests  a fully  Initialized  system.  At  present  the 
system  bootstraps  Itself  In  a coaplex  way  each  time  It  Is  loaded 
from  a tape  containing  the  separate  pieces.  The  new  pattern  of 
operation  removes  most  Initialization  software  from  the  kernel. 
The  correct  Initialization  of  the  kernel  also  should  be  easier  to 
verify*  for  most  of  the  work  of  Initial Izatlon  will  occur  when 
the  tape  Is  made*  In  the  stable  environment  of  a fully 
Initialized  system. 

Another  activity  Is  exploiting  the  equivalence  between 
entering  a protected  subsystem  and  creating  a new  process  In 
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response  to  a user’s  log-ln.  The  goal  Is  to  make  a single 
mechanism  do  both  tasks*  so  that  the  privileged*  protected  code 
used  to  authenticate  and  log-ln  users  can  be  executed  In  the  user 
code  protection  environment.  The  authentication  algorithm  still 
must  be  verified  not  to  Malfunction  If  the  user  trying  to  log-ln 
behaves  unexpectedly.  Such  verification  should  be  easy*  however* 
since  the  user/systea  Interface  severely  Halts  user  behavior. 

The  second  category  of  activities  Is  restructuring 
nechanlsas  that  must  remain  In  the  kernel.  Such  activities  can 
reduce  both  the  size  and  the  complexity  of  the  kernel.  In  some 
cases  a piece  of  the  kernel  can  be  eliminated  and  Its  function 
assumed  by  another  kernel  mechanism.  For  example*  one  activity 
Is  exploring  replacement  of  all  external  I/O  mechanisms  (to 
terminals*  tape  drives*  card  readers*  card  punches*  and  printers) 
with  the  ARPA  Network  attachment.  This  would  eliminate  many 
special  mechanisms  for  managing  I/O  devices  and  leave  a single 
mechanism  for  managing  the  network  attachment.  Internal  I/O 
functions  (for  managing  the  virtual  memory*  performing  backup* 
and  loading  the  system)  would  still  be  managed  In  the  kernel. 

A proposed  buffering  strategy  for  network  Input  uses  the 
virtual  memory  to  provide  a core  resident  buffer  that  appears  to 
be  Infinite  In  length.  With  the  present  circular  buffer*  which 
has  to  be  used  over  and  over*  complex  mechanisms  are  required  to 
cope  with  messages  not  removed  before  a complete  circuit  of  the 
buffer  Is  made.  The  circular  buffer  scheme  Is  really  providing  a 
special-purpose  storage  management  facility.  The  proposed 
Infinite  buffer  uses  Instead  the  standard  storage  management 
facility  of  the  system — the  virtual  memory. 

Several  restructuring  activities  Involve  the  Implementation 
and  use  of  processes.  One  activity*  now  nearing  the  end  of  the 
design  phase*  Is  a relap  I ementatlon  of  processes  using  two  layers 
of  mechanism.  (8)  This  new  design  simplifies  the  Interaction  of 
the  process  Implementation  with  the  virtual  memory  management 
mechanisms.  It  also  simplifies  the  base-level  Interprocess 
communication  mechanisms  of  the  system.  The  first  level  of 
mechanism  multiplexes  the  processors  Into  a larger  fixed  number 
of  virtual  processors.  Because  the  number  of  virtual  processes 
Is  fixed*  this  layer  need  not  depend  on  the  mechanisms  for 
managing  the  virtual  memory.  Several  of  the  virtual  processors 
are  permanently  assigned  to  Implement  processes  for  the  dedicated 
use  of  other  kernel  mechanisms*  Including  the  virtual  memory 
management  mechanism.  The  remaining  virtual  processors  are 
multiplexed  by  the  second  layer  of  the  process  Implementation 
Into  any  desired  number  of  full  Hul tics  processes  that  execute  In 
the  virtual  memory.  Use  of  the  proposed  base-level  Interprocess 
communication  facility  can  be  controlled  with  the  standard  memory 
protection  mechanisms. 


(8)  This  Idea  Is  being  explored  by  others  as  well  (3*19). 
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The  1 no  I e went at  Ion  (implied  above)  of  certain  Kernel 
mechanisms  as  asynchronous  parallel  processes  also  sieplifies 
system  structure*  which  now  forces  many  supervisor  mechanisms 
into  sequential  algorithms*  The  virtual  memory  mechanisms  for 
moving  pages  among  the  three  levels  of  the  memory  hierarchy  are  a 
good  example.  Whenever  a missing  page  fault  occurs  in  a process* 
the  fault  handler  attempts  to  initiate  the  transfer  of  the 
desired  page  from  bulk  store  or  disk  to  primary  memory.  This  can 
be  done  only  if  a free  primary  memory  block  is  available.  If 
none  is  available  the  fault  handler  must  move  a page  from  primary 
memory  to  the  bulk  store  to  make  room.  This*  in  turn*  is 
possible  only  if  a free  block  of  bulk  store  is  available.  If 
not*  a page  must  be  moved  from  the  bulk  store*  via  primary 
memory*  to  a disk.  At  present*  this  series  of  steps  occurs 
sequentially  with  the  algorithms  executing  in  the  process  that 
took  the  page  fault*  and  then  in  various  other  user  processes 
that  happen  to  receive  the  subsequent  I/O  interrupts.  The  new 
scheme  involving  multiple  dedicated  processes  is  much  simpler. 
One  process  makes  sure  that  some  small  number  of  free  primary 
memory  blocks  always  exist.  Whenever  the  number  of  free  primary 
memory  blocks  drops  below  that  number*  this  process  transfers 
pages  to  bulk  store.  Another  process  keeps  space  free  on  the 
bulk  store  by  moving  pages  to  disk  when  required.  Signals  from 
processes  that  have  taken  a page  fault  and  not  found  free  prieary 
memory  blocks  activate  the  process  that  frees  primary  memory. 
The  process  that  frees  bulk  store  blocks  is  driven  in  a similar 
manner  by  signals  from  the  process  that  frees  primary  memory 
blocks.  The  path  taken  by  a user  process  on  a page  fault  is 
greatly  simplified.  This  process  can  Just  wait  until  a prieary 
memory  block  is  free  and  then  initiate  the  transfer  of  the 
desired  page  into  priaiary  memory. 

Interrupt  handling  is  another  possible  application  of 
processes  in  the  kernel.  Each  interrupt  handler  would  be 
assigned  its  own  process  in  which  to  execute*  rather  than  being 
forced  to  inhabit  whatever  user  process  was  running  when  the 
Interrupt  occurred.  As  a resul t*  the  system  Interrupt 
Interceptor  could  turn  each  Interrupt  into  a signal  to  the 
corresponding  process.  Being  processes*  the  interrupt  handlers 
could  use  the  normal  system  interprocess  communication  mechanisms 
to  coordinate  their  activities  with  one  another  and  user 
processes*  greatly  simplifying  their  structure.  The  problem  to 
solve  here  is  Implementing  the  Interrupt  processes  so  that  system 
performance  is  not  degraded. 

A major  activity  is  restructuring  the  portion  of  the  file 
system  that  must  remain  in  the  kernel.  This  software  implements 
the  directory  hierarchy  and  manages  the  virtual  memory  at  the 
level  of  segments.  Work  in  this  area  is  Just  beginning*  but 
three  changes  with  a potential*  significant  cumulative  effect  are 
promising  first  steps.  One  change  is  removing  physical 
attributes  of  segments  from  directory  entries.  The  physical 
attributes  will  be  recorded  in  data  bases  associated  with  the 
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various  secondary  storage  devices*  (This  modification  is  being 
implemented  as  part  of  a file  system  overhaul  done  by  Honeywell 
for  other  reasons*)  The  second  change  is  removing  storage  quotas 
from  directory  entries*  recording  them  Instead  in  a separate 
(possibly  hierarchical)  data  structure*  The  third  is  eliminating 
the  dependence  of  the  file  backup  mechanism  on  the  date-time 
modified  information  recorded  in  directory  entries  and  reflected 
up  the  hierarchy  toward  the  root.  Eliminating  this  dependence 
will  allow  the  date-time  modified  item  to  be  removed  from 
directory  entries  as  well.  Backup  will  be  driven  by  a queue  of 
requests  from  the  machinery  that  controls  deactivation  of 
segments  from  primary  memory.  As  a result  of  these  three 
changes*  it  appears  that  the  management  strategy  for  the  Active 
Segment  Table  can  be  modified  to  eliminate  the  need  for  holding 
active  the  superior  directories  of  an  active  segment  111). 

The  various  restruc turlng  activities  eventually  will  extend 
to  all  parts  of  the  kernel*  and  to  its  overall  structure. 

The  third  category  of  activities  is  partitioning  the  kernel 
into  differently  protected  pieces  to  modularize  the  Job  of 
matching  the  kernel  to  the  system  security  specification.  (9) 
The  specific  projects  in  this  category  are  not  as  well  developed 
as  the  others.  There  appear  to  be  several  different  design 
principles  with  which  to  generate  the  kernel  partitions*  and  it 
is  not  yet  clear  which  proouces  the  kernel  that  is  easier  to 
verify.  To  illustrate  two  possible  approaches  to  partitioning  a 
kernel  into  multiple  domains*  imagine  that  the  security 
specification  is  expressed  as  a set  of  security  properties*  each 
of  which  must  be  met.  One  design  principle  is  to  divide  the 
kernel  into  domains  arranged  so  that  each  property  is  implied  by 
a subset  of  the  domains.  Then*  to  verify  that  the  kernel 
implements  the  security  specification*  an  independent 
verification  of  each  property  is  required*  but  each  involves  only 
a subset  of  the  domains  in  the  kernel.  Another  design  principle 
is  to  ignore  any  structure  suggested  by  the  security  properties 
and  divide  the  kernel  into  domains  according  to  some  other 
principle  of  structured  programming  (for  example*  Parnas*  notion 
of  information  hiding  (20))  so  that  each  domain  has  a simple 
Interface  behavior  specification.  Verification  of  each  of  the 
security  properties  may  Involve  all  the  kernel  domains*  but  once 
each  domain  has  been  verified  to  match  its  Interface 
specification*  then  only  these  specifications  need  be  considered 
to  verify  each  security  property.  kh  ich  of  these  two  approaches 
is  preferable — or  indeed*  whether  they  really  are  different 
approaches — remains  to  be  seen. 


(9)  Partitioning  is  really  the  same  problem  as  dividing  the 
kernel  into  separate  procedures  and  data  bases*  with  the  extra 
property  that  the  modularity  is  enforced  by  the  system's 
protection  mechanisms 
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Two  specific  Methods  for  partitioning  the  Multics  Kernel  are 
available.  The  first  is  dividing  the  part  of  the  Kernel  that  is 
in  the  address  space  of  each  process  Into  Multiple  layers  in 
different  rings  of  protection.  The  second  is  placing  soae  of  the 
Kernel  processes  in  separate  address  spaces  and  also  using  the 
protection  rings  to  layer  theM.  Several  suggestions  have  been 
Made  for  layering  the  part  of  the  Kernel  that  is  in  each  user 
process.  One  is  that  the  bottoe  layer  Implement  a file  system  in 
which  all  segeents  were  named  by  system-generated  unique 
identifiers.  The  next  layer  would  implement  a naming  hierarchy 
on  top  of  the  priMltlve  first-layer  file  system.  Another 
suggestion  is  that  mechanisms  to  provide  the  nondlscret ionary 
controls  on  the  flow  of  information  among  processes  be 
implemented  at  the  bottom  and  mechanisms  to  control  dlscret ionary 
sharing  within  the  constraints  of  the  nondiscretionary  controls 
be  implemented  in  the  next  layer.  This  last  suggestion  is 
particularly  intriguing*  because  if  correctly  done*  the  notion  of 
minimizing  common  mechanisms  would  be  well  supported.  The 
second-layer  mechanisms  would  be  common  only  within  the  access 
constraints  enforced  by  the  first  layer. 

Partitioning  through  use  of  separate  address  spaces  for 
Kernel  processes  is  being  considered  in  the  case  of  the  processes 
that  manage  the  various  system  resources.  The  protection  rings 
in  these  processes  then  could  be  used  to  separate  the  policy  and 
mechanism  components  of  the  resource  managers.  (10)  For  example* 
the  process  described  earlier  that  removed  pages  from  prieary 
memory  could  be  given  its  own  address  space  with  multiple  rings. 
Programs  in  the  most  privileged  ring  would  Implement  the 
mechanics  of  page  removal*  providing  gate  entry  points  for 
requesting  the  movement  of  a particular  page  from  primary  memory 
to  a particular  free  blocK  on  the  bulk  store*  and  for  obtaining 
usage  information  about  pages  in  primary  memory.  The  policy 
algorithm  that  decides  which  page  to  remove  when  another  free 
primary  memory  block  needs  to  be  generated  would  execute  in  a 
less  privileged  ring*  calling  the  gate  entry  points  to  collect 
the  necessary  usage  statistics  and  to  do  the  actual  moving*  once 
a decision  was  made.  The  policy  algorithm*  however*  could  never 
read  or  write  the  contents  of  pages*  learn  the  segment  to  which 
each  page  belonged*  or  cause  one  page  to  overwrite  another.  Such 
operations  would  not  be  available  in  its  ring  of  execution.  The 
result  is  that  the  policy  algorithm  could  never  cause 
unauthorized  use  or  modification  of  the  information  stored  in  the 
pages.  It  could  only  cause  denial  of  use.  Under  the 
circumstance  that  denial  of  use  was  deemed  less  serious  than  the 
other  security  violations*  the  policy  algorithm  need  not  be  as 
carefully  verified  as  the  rest  of  the  Kernel.  It  appears  that 
the  idea  of  separating  policy  from  mechanisms  applies  to  all 
resource  management  processes. 


(10)  Separation  of  policy  from  mechanism  is  a structural 
principle  that  has  been  explored  by  many  others  121*22*23). 
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This  paper  has  presented  the  plan  for  a research  project  to 
evolve  the  Hultics  supervisor  into  a security  kernel  capable  of 
supporting  the  functionality  of  Hultics  completely  and 
efficiently.  It  has  described  a sample  of  the  specific 
strategies  being  employed.  The  broad  objective  is  finding  Mays 
to  reduce  the  size  and  complexity  of  the  software  that  must  be 
correct  for  a shared  general-purpose  system  to  be  secure. 
Reduced  size  and  complexity  of  security-relevant  software  is  a 
prerequisite  to  performing  a convincing  logical  verification  that 
a system  correctly  implements  the  claimed  access  constraints,  no 
matter  what  verification  techniques  are  used.  Without  such 
verification  of  correctness,  a system  cannot  be  considered 
secure. 

At  the  time  this  paper  is  being  written.  the  project  has  run 
for  about  half  of  its  intended  four  year  span,  and  most  of  the 
initial  tasks  are  nearing  completion.  So  far.  the  expected 
reductions  in  size  and  simplifications  of  structure  of  the 
security-relevant  software  seem  to  be  occur ing.  It  is  too  soon 
to  tell,  homever,  whether  the  security  kernel  for  Hultics  that 
will  result  will  be  sufficiently  small  and  simple  to  be 
understood  in  detail  by  one  person. 

AChfWHlfldflfifflQlS 

In  describing  a group  project  of  the  Computer  Systems 
Research  Oivision  of  Project  HAC  at  H.I.T..  this  paper  discusses 
the  work  of  several  faculty  members,  graduate  students*  and  staff 
members  in  the  Oivision.  Rather  than  list  all  here,  they  will 
receive  credit  for  their  contributions  as  specific  activities  are 
completed  and  reported  separately.  Preparation  of  this  paper  was 
aided  by  written  commentaries  on  various  drafts  provided  by  E. 
Cohen.  F.  Corbatb.  R.  Fabry.  0.  Hunt.  P.  Janson.  0.  Reed.  J. 
Saltzer*  and  R.  Schell,  and  by  comments  from  0.  Clark.  A.  Jones, 
and  0.  Rede  1 1 • 
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